An ad hoc wireless network is a self-configuring and self-healing localized wireless network that is used to enable communication among a plurality of mobile devices. Connectivity to remote databases or networks is made possible through at least one access point that is connected to such resources over a backhaul network. Mobile devices such as cellular phones, personal digital assistants (PDAs) and notebook computers that operate in ad hoc wireless networks often require authentication when communicating with one another, and when accessing remote databases or networks. A trusted communication path can be established between communicating mobile devices, wherein one device may gain trust in another through a sequence of predominantly logical trust steps.
A public key infrastructure (PKI), built upon asymmetric cryptographic systems, can be used to enable mobile devices to authenticate one another. In an asymmetric cryptographic system, encryption and decryption of data are performed using different keys, one of which is kept secret and the other is safely divulged as needed. In a PKI, there is at least one trusted entity, known as a certification authority (CA), which issues data structures (referred to as certificates) that bind specific identities to specific public keys and usage information via digital signatures. The CAs are trusted a priori based on their public keys that are known to be bound to their respective identities in advance. Entities other than CAs may establish trust among themselves by showing one another their respective certificates issued by trusted CAs. There may be a plurality of CAs in a given PKI domain, wherein the CAs may have a hierarchical or a meshed relationship among them. Trust relationships among CAs can be used to build a certification path, which is a chain of certificates where each certificate in the chain is validated by its preceding certificate's public key. A certificate path must terminate with a certificate that has a trusted public key, so that a verifier of the certificate path can verify, using the trusted public key (referred to as a trust anchor of the verifier), a certificate at the other end of the certificate path.
As described above, when a certificate is produced by an entity (referred to as a target) to demonstrate proof of possession of a valid public key, a verifier of the certification needs to construct a certificate path linking the verifier's trust anchor to the certificate. In a multi-organizational environment, where each organization has its own PKI domain, applications supporting inter-organizational security require additional mechanisms to establish cross-organizational trust relationships, since certificate paths normally remain within respective PKI domains.
One method for addressing interoperability issues to support inter-organizational security involves use of cross-certificates, wherein CAs of different organizations cross sign one another's certificates to enable members in one organization to trust all user certificates issued by each cross-certified CA. To avoid scalability issues due to meshed CA cross-certification, a bridge CA may be used to cross sign certificates with each participating CA, such that members of each organization can trust all certificates issued by cross-certified CAs. However, both the above methods are undesirable for establishing inter-organizational trust among disparate organizations that have specific and limited relationships. Such disparate organizations have to rely on predetermined policy constraints on certificate validation, where policy rules may include, for example, constraints on at least one of path length, domain name, and assurance level. Certificate validation therefore can be complicated by policy rules that may be required for large PKI domains.
Referring to FIG. 1, a network diagram illustrates a problem with cross-certification techniques, as known according to the prior art. Consider, for example, that a first organization has a Root1 certification authority (CA) 105 and several subordinate department CAs, including an engineering department Eng_1 CA 110, a marketing department Mkt_1 CA 115, and a finance department Fin_1 CA 120. Consider also that a second organization has a similar CA hierarchy, including, for example, a Root2 certification authority (CA) 125, a finance department Fin_2 CA 130, and an engineering department Eng_2 CA 135.
In order to limit a level of cross-organizational trust between the first and second organizations, consider that Fin_1 CA 120 issues a cross-certificate 140 to Fin_2 CA 130 wherein the cross-certificate is a certificate of Fin_2 CA 130 cross-signed by Fin_1 CA 120. A user 145 in the finance department of the second organization may thus use the cross-certificate 140 to gain the trust of a user 150 in the finance department of the first organization. However, the cross-certificate 140 may not effectively prevent the user 145 in the finance department of the second organization from also gaining the trust of the engineering and marketing departments of the second organization. That is because a user 155 in the marketing department and a user 160 in the engineering department of the second organization are not limited to using only the Eng_1 CA 110 and the Mkt_1 CA 115 as trust anchors. In addition, the users 155, 160 also can use the Root1 CA 105 as a trust anchor. The cross-certificate 140 thus creates a valid certificate path from the Root1 CA 105, to the Fin_1 CA 120, to the Fin_2 CA 130.
To overcome the above described problem of abuse of cross-organizational trust, one method includes policy constraints on certificate validation. For example, in addition to issuing cross-certificates at subordinate CAs, a policy statement is provided between each hierarchically superior CA and subordinate CA to control a range of security domains defined by each cross-certificate. Such a policy statement may indicate, for example, that an associated cross-certificate cannot be used to validate a level of trust beyond a security domain subordinate to Fin_1 CA 120. For example, referring again to FIG. 1, to prevent the cross-certificate 140 from being used to establish trust between the user 155 in the marketing department of the first organization and the user 145 in the finance department of the second organization, a policy statement would be required between the Root1 CA 105 and the Fin_2 CA 130.
According to another method, a trust bridge (TB) is used to establish an inter-organizational trust link where a sequence of logical trust steps crosses an organizational boundary. A TB is a device that has been configured with a predetermined set of trust anchors associated with a plurality of organizations with autonomous security domains, and a certificate signed by each of the trust anchors. A device affiliated with an organization may issue a request to a TB in order to bridge authentication between that organization and another organization. A TB must have acquired a certificate from a CA of each participating organization, so that the TB can be trusted by, and can authenticate, relying parties (i.e., certificate verifiers) from different participating organizations. A TB then can assist two relying parties to establish a session key to be used to encrypt data subsequently exchanged between the relying parties. A TB can also assist one relying party to verify authenticity of a message sent by another relying party. A TB also can be responsible for maintaining a status of a certification revocation list, which is a record of certificates that have been revoked.
There exist several methods to enable relying parties to discover candidate TBs that can bridge their corresponding organizations. These methods enable advertising and discovery of devices that can provide such bridged trust services over an ad hoc wireless network. Compared to the methods of cross-certification and bridged CA as described above, trust bridge based methods can offer increased flexibility in range control, without a burden of complicating backhaul CA relationship topology. However, a trust bridge can be another target for security attack in a trust chain. Moreover, the task of bridging trust can be computationally intensive as trust bridges may need to handle certificate management for all organizations participating in a network.
Accordingly, there is a need for an improved method and device for deploying trust bridges in an ad hoc wireless network to provide interoperability for multi-organizational authentication.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.